+1 on this. Can we get this merged?

+1, this would be really valuable for my use-case as well! Would be great if this were supported.

+1

+1, can we help to get it merged ?

+1, this would be really useful

@mbostock ?

The issue I see with this design is that you can’t run the Sankey layout again on the same input: the node.value set by the previous run of the Sankey layout becomes the new minimum value of the node. So, this is not strictly backwards-compatible.

We tackled a similar issue in d3/d3-hierarchy#9 by wrapping the input data, so that the layout isn’t overwriting the same value it reads from. I think we’ll probably want to do that with the Sankey input, too—to treat the input data as immutable, and to wrap it with whatever the layout generates.

A super-simple way of avoiding this problem would be to read from node.minValue instead.

Thanks, yes that seems a much better design - added in c03678f.

Thanks. Would it be better specify a node.fixedValue, rather than a node.minValue? Then you would say:

node.value = node.fixedValue === undefined
    ? Math.max(sum(node.sourceLinks, value), sum(node.targetLinks, value))
    : node.fixedValue;

I figured this might cause a rendering problem if the nodes were smaller than the incoming links?

Yep, but isn’t that more of a data problem than a rendering problem? It seems better to do that than to ignore the input value.

Yes, makes sense. Looks good to me.

Hi, what is the state of this pull request? This function would be very useful for us. Can I help?

Thanks